home *** CD-ROM | disk | FTP | other *** search
/ The Arsenal Files 8 / The Arsenal Files Collection #8 (Arsenal Computer) (1996).ISO / g_quake / elimtst1.zip / ELIMWPT.TXT < prev    next >
Text File  |  1996-09-15  |  15KB  |  466 lines
  1. Eliminator Bot Waypoint Guide
  2. -----------------------------
  3.  
  4. For Version 1.0/1.1
  5. By Cameron Newham (cam@iinet.com.au)
  6.  
  7.  
  8. CBot Engine "Home Page":   http://www.iinet.com.au/~cam/quakec.html
  9.  
  10.  
  11. INTRODUCTION
  12. ------------
  13.  
  14. The Eliminator Patch for Quake has at its heart a "waypoint" system
  15. for cbot navigation.  The basic idea is that a cbot (powered by
  16. a program written in Quake C - the CBot Engine) looks for the nearest
  17. waypoint in a level and then heads towards it.  Waypoints are
  18. daisychained together, so that once the cbot has aquired the waypoint
  19. (by standing within a short distance of it) it reads the information
  20. on the location of the next waypoint in the daisychain and heads
  21. towards that.
  22.  
  23. Waypoints exist as entities in a level - that means that they can be
  24. added to a Quake MAP file, compiled into a BSP and will be available
  25. every time the level is loaded.
  26.  
  27. Advantages:
  28.  
  29.   * Navigation and AI code is vastly simplified
  30.   * The cbots will act with the same cunning as the person who
  31.     codes the waypoints
  32.   * Any MAP or BSP file can have waypoints added to it to convert
  33.     it to an "Eliminator Bot Level"
  34.   * The waypoint info is stand alone and doesn't require the Engine
  35.     source code
  36.   * The maps can be used as normal if you don't run the Engine (and
  37.     will work with any other patches you have)
  38.   * Waypoint information is transparent to the players - the maps
  39.     can be used on servers without having the clients download
  40.     special files
  41.   * Waypoint definitions are compact ASCII text - they can be
  42.     added to the end of any MAP file for compilation into a BSP
  43.  
  44. Disadvantages:
  45.  
  46.   * Requires that you have the entity definitions for a MAP
  47.     (but these can be extracted from the BSP if you don't have
  48.     the MAP file)
  49.   * Uses entities in Quake (there is a maximum limit) and uses
  50.     memory
  51.   * Requires a good understanding of the Engine and the Quake
  52.     maps (but nothing that can't be learnt by trial and error)
  53.     if you wish to build a waypoint system
  54.  
  55.  
  56. DETAILS
  57. -------
  58.  
  59. Definitions
  60.  
  61. waypoint - a waypoint entity in a map file
  62. pathway  - a path that a cbot will follow, defined by waypoints
  63.  
  64.  
  65. When a cbot is generated at a Deathmatch location it does two things:
  66.  
  67.  1 looks for weapons and armour within about 200 units of itself
  68.    and grabs them if if it finds them
  69.  
  70.  2 looks for the nearest General or Item waypoint
  71.  
  72. There are two types of waypoints: General and Item. The Item waypoints
  73. are split into sub-catagories; one for each type of armour and weapon.
  74. There are no specific waypoints for ammo, health or specials. These
  75. are calculated on-the-fly by the Engine and are only used in "need to
  76. have" situations (eg: low on health, etc).
  77.  
  78. The type of waypoint is given in the "items" field of a waypoint
  79. definition.  The following table lists the supported definitions:
  80.  
  81.  
  82. items   priority     waypoint type and sub-type
  83. -----   --------     --------------------------
  84. 0       -            General
  85. 11      9            Super Shotgun
  86. 12      8            Nail Gun
  87. 13      7            Super Nailgun
  88. 14      6            Grenade Launcher
  89. 15      5            Lightning Gun
  90. 16      4            Rocket Launcher
  91. 21      3            Green Armour
  92. 22      2            Yellow Armour
  93. 23      1            Red Armour
  94.  
  95.  
  96. The items is the value you place in the "items" field of a waypoint
  97. definition.
  98.  
  99. The priority is used by the Engine to determine which waypoints to
  100. take if there are multiple ones available (depending of course
  101. on what items the cbot already has in its inventory).  This is
  102. just here for your reference (the values are implicit in the waypoint
  103. type and are not part of the waypoint definition).
  104.  
  105. Waypoints also have another catagorisation: Waypoint or Endpoint.
  106. Endpoints are just waypoints with nothing to daisychain to. For instance,
  107. say we had the following path (showing waypoint names):
  108.  
  109. g1---------->g2----------->g3----------->g4
  110.  
  111. g1 daisychains to g2, g2 to g3, g3 to g4, and g4 to nothing.  In this
  112. case, g1, g2, and g3 are normal Waypoints and g4 is an Endpoint.
  113. In most cases the word "waypoint" can mean either a Waypoint or
  114. an Endpoint.  We use capitalisation in this document to refer to
  115. the specific case, and lowercase to refer to them in the general
  116. sense.
  117.  
  118.  
  119. General Waypoints
  120.  
  121. The structure of a General waypoint is:
  122.  
  123. {
  124. "classname" "cn_wpt"
  125. "origin" "544 808 -8"
  126. "targetname" "g1"
  127. "target" "g2"
  128. "items" "0"
  129. }
  130.  
  131. classname  :  the entity classname that Quake and the Engine will use.
  132.               must be "cn_wpt" for a cbot waypoint
  133. origin     :  the X/Y/Z position of the waypoint in the level
  134. targetname :  The name of the waypoint (can be anything, but you are
  135.               better off following a convention, eg: g1, g2, g3, etc
  136.               for General waypoints)
  137. target     :  the name of the next waypoint in the daisychain.  This has
  138.               to be a "-" if this waypoint is an Endpoint.
  139. items      :  the type of waypoint
  140.  
  141.  
  142. You can do what you like with the daisychaining; a circular path can be
  143. created by making the "target" of the last waypoint the same as the
  144. "targetname" of your first waypoint (in which case your path will have no
  145. Endpoint).  If you make a waypoint point to itself, the cbot will just
  146. wander aimlessly around the point (not very useful).
  147.  
  148. Waypoints should also be in line-of-sight in the daisychain. You can
  149. get away with having them slightly out of sight, so long as the cbot
  150. has a clear passage to the next waypoint, with glancing blows off
  151. walls (oblique to the wall) acceptable.  eg:
  152.  
  153.  
  154. ============================+
  155. * g1                        |
  156.   ----\       cbot path     |
  157.        ----\                |
  158.             ----\           |
  159.  =================          |
  160.                  |* g2      |
  161.  
  162.  
  163. Another situation in which a waypoint can be out of sight is when you
  164. want the cbot to take a lift (rising platform).  You can make the vertical
  165. (Z) components quite different and it will work quite well:
  166.  
  167.                 _g2  floor level = 350
  168.                |
  169.               _|
  170.              |#| lift
  171. g1           |#|
  172. -------------+ +
  173. floor level = 10
  174.  
  175.  
  176. A cbot will follow the path from the nearest Waypoint it can find (it
  177. ignores Endpoints) until it reaches an Endpoint.  A good example
  178. of this is in the Start map - the very first and second waypoint definitions*
  179. define a line from the entrance of the middle corridor to the entrance
  180. of the teleport in the middle corridor.
  181.  
  182. (* in Release 1.1 this has changed to the 2nd and 3rd definitions)
  183.  
  184.  
  185.  
  186. Item Waypoints
  187.  
  188. These are basically the same as General waypoints, but have their
  189. items field set to a particular item that they lead to.  You should
  190. keep the items field the same for all waypoints within a given item
  191. pathway.
  192.  
  193. Item pathways don't have to lead right onto the targetted item. Once
  194. a cbot hits the Endpoint of an Item pathway it will search for nearby
  195. items and grab them.  The Endpoint should be within about 200 units
  196. of the item and should be in direct line of sight from the item.
  197. This is MOST important!
  198.  
  199.  
  200. Waypoint Modifiers
  201.  
  202. You might have noticed that the cbots jump into teleporters and they
  203. can jump over the lava area in the Start level.  You can force the
  204. cbot to jump by adding three pieces of information to the waypoint:
  205.  
  206. {
  207. "classname" "cn_wpt"
  208. "origin" "544 1330 -8"
  209. "targetname" "g2"
  210. "target" "-"
  211. "items" "0"
  212. "speed" "205"
  213. "angle" "90"
  214. "height" "220"
  215. }
  216.  
  217. speed  : the forward velocity of the cbot
  218. angle  : the compass direction of the jump
  219. height : the vertical velocity of the jump
  220.  
  221.  
  222. The cbots are incapable of pressing floor mounted buttons by just
  223. walking over them. you can use a special jump to activate a button
  224. underneath a waypoint:
  225.  
  226. {
  227. "classname" "cn_wpt"
  228. "origin" "-767 2143 330"
  229. "targetname" "g8g"
  230. "target" "g8h"
  231. "items" "0"
  232. "jump_flag" "1"
  233. }
  234.  
  235. jump_flag : jump a tiny amount at this point
  236.  
  237. The amount they jump is not noticable in game-play.  Use the full
  238. blown jump definition for normal jumping.
  239.  
  240.  
  241. Any Waypoint can have an optional daisychain.  The option is given
  242. a 50% chance of being used as the next waypoint:
  243.  
  244. {
  245. "classname" "cn_wpt"
  246. "origin" "-125 2555 350"
  247. "targetname" "g8"
  248. "target" "g9"
  249. "noise4" "g10"
  250. "items" "0"
  251. }
  252.  
  253. noise4 : an optional target name
  254.  
  255. In this case, g8 points to both g9 and g10. There is a 50% chance
  256. of the cbot choosing g9 as its goal and a 50% chance of it choosing
  257. g10.
  258.  
  259.  
  260.  
  261. A waypoint can have a camping position defined.  Under certain conditions
  262. (currently :-   weapon: R/L, LG, G/L or SNG, armour: >40%, health > 70%,
  263. and a 60% probability of taking the option) a cbot has the capability to
  264. "camp" (stand motionless, waiting for an enemy). The camping position
  265. is defined by three fields:
  266.  
  267. {
  268. "classname" "cn_wpt"
  269. "origin" "-10 2293 88"
  270. "targetname" "w5"
  271. "target" "-"
  272. "items" "14"
  273. "button0" "1"
  274. "view_ofs" "88 2486 88"
  275. "angle" "200"
  276. }
  277.  
  278. button0  : a boolean indicating this has a camping definition field (use 1)
  279. view_ofs : the X/Y/Z co-ordinates of the camping position
  280. angle    : the compass direction to face when standing at the camping position
  281.  
  282.  
  283.  
  284. A waypoint can instruct the cbot to swim.  Normally a cbot will attempt
  285. to walk in water, but by using the swim flag, you can make them swim.
  286. This is useful if the water has no solid floor (eg: the pool in the Start
  287. level) or if you want them to swim to a point out of reach by walking
  288. on the floor.
  289.  
  290. {
  291. "classname" "cn_wpt"
  292. "origin" "1150 1724 60"
  293. "targetname" "a3"
  294. "target" "-"
  295. "items" "23"
  296. "swim_flag" "1"
  297. }
  298.  
  299. swim_flag : start swimming *after having read this waypoint definition*
  300.  
  301. This flag operates slightly differently to the others in that it is acted
  302. on as soon as the co-ordinates of the waypoint are read, NOT when the cbot
  303. reaches the waypoint.  If you had the following pathway:
  304.  
  305.   g1---------->g2---------->g3
  306.  
  307. and you wanted the cbot to swim from g2 to g3, then you would place the
  308. swim_flag at waypoint g3.
  309.  
  310.  
  311.  
  312.  
  313. TIPS
  314. ----
  315.  
  316. Having written the CBot Engine and placed waypoint definitions in two
  317. maps, I know well the problems that you are likely to encounter.  Part
  318. of the secret of making the cbots appear intelligent is good waypoint
  319. design.  If you have carefully thought out what routes you want them to
  320. take, there is no reason why they shouldn't do extremely well in a
  321. deathmatch situation.
  322.  
  323.  
  324. Common Errors
  325. -------------
  326.  
  327. * vertical positioning of waypoints
  328.  
  329. When running around a level in Quake taking positional measurements,
  330. add 5 to 10 units to the vertical position so that the waypoints
  331. are clearly visible over low objects.
  332.  
  333.  
  334. * placing an Endpoint too near a teleport
  335.  
  336. In this case the cbot may touch the teleport *before* detecting the
  337. Endpoint.  That will leave it searching for the Endpoint at the teleport
  338. destination - obviously not the ideal situation.
  339.  
  340. To make cbots take teleports, make them jump into the teleport from some
  341. distance (about 40 or 50 units) away.  Always use Endpoints at the
  342. teleport jump - this ensures that the cbot will reinitialise itself
  343. at the destination and correctly aquire other waypoints.
  344.  
  345.  
  346. * incorrect swimming
  347.  
  348. Make sure the swim_flag is in the correct waypoint definition - see my
  349. description above.
  350.  
  351.  
  352. * failure to run over certain floors, into water and over ledges
  353.  
  354. id have made their movement code such that monsters (and bots) can't
  355. move over discontinuities in the floor (a discontinuity being where
  356. the floor height differs by a large ammount - probably 8 or 10 units).
  357. A good example of this is in the Start level near the Rocket Launcher.
  358. The zig-zag on the floor has lots of discontinuities and causes no
  359. end of trouble for would-be-bot-designers.
  360.  
  361. The same goes for water - the surface of the water is *not* a floor
  362. level.
  363.  
  364. Discontinuities are automatically taken care of by the Engine - it makes
  365. the cbots jump (currently the only effective way of doing it, although
  366. I know another way that is the bees-knees, but it's not in the Engine
  367. at this time).  The jump is pretty well random.
  368.  
  369. Obviously this is not ideal if you want the cbot to move accurately - in
  370. that case make a waypoint near the water/ledge that is a jumping point.
  371.  
  372.  
  373. * cbots are on a pathway and then start jumping randomly
  374.  
  375. You probably have made one of the waypoints unreachable. If the cbot hits
  376. a wall and gets stuck, it will reinitialise itself and try and aquire
  377. the nearest waypoint. If there are none in sight it will start jumping.
  378. In all cases this is *your* fault :)  Make SURE that the pathways are
  379. defined according to the rules given above.  I can't stress this enough.
  380. In all cases CHECK THEM YOURSELF BY RUNNING QUAKE AND FOLLOWING YOUR PATH.
  381.  
  382.  
  383. * placing waypoints near a ledge causes the cbots to jump randomly
  384.  
  385. You must allow some over-shoot on the waypoints. It appears that if the
  386. bounding-box of the model moves over a floor discontinuity then id's
  387. movement code will go into "wall search mode".  This will, in turn,
  388. cause my code to run its unsticking routine.
  389.  
  390. Place your waypoints at least 12 units back from ledges (floor discontinuities).
  391.  
  392.  
  393. * the cbot is running on a pathway to a nailgun when it suddenly changes
  394.   direction and goes somewhere else
  395.  
  396. Don't forget that the waypoints are prioritised.  If a cbot is on an
  397. item path and it detects another item path for a higher priority item,
  398. it will swap to the new path (unless, of course, it already has the higher
  399. priority item).
  400.  
  401.  
  402. * the cbots seem to get confused after a firefight and just start jumping
  403.  
  404. You have a severe lack of general waypoints. You should aim to have at
  405. least one general waypoint (part of a pathway, not stand-alone!) visible
  406. from every accessible area of the level.  Even if you don't, there should
  407. be one in each room so that cbots that fail to aquire a waypoint have
  408. a reasonable chance of doing so when they go into "unstick" mode (start
  409. jumping).
  410.  
  411. Also make sure that there is a pathway start near each Deathmatch teleport
  412. location.
  413.  
  414.  
  415. * what about health and specials (quad, etc)?
  416.  
  417. The cbots determine when to pick these up. If you want to give them
  418. the opportunity to do so, place a pathway (not necessarily a waypoint -
  419. the search for these items is on-the-fly) no further than 200 units away
  420. from the items.
  421.  
  422.  
  423. * how do I find out the X/Y/Z locations and test the maps?
  424.  
  425. See the next section.
  426.  
  427.  
  428.  
  429. CREATING AND TESTING LEVELS
  430. ---------------------------
  431.  
  432. I will provide a progs.dat file with the level debugging switched on.
  433.  
  434. Level Debugging includes:
  435.  
  436. * printout of current location and compass direction (impulse 202)
  437. * creation of a cbot a little way ahead of you (impulse 166)
  438.  
  439. PLEASE do NOT use the debugging version as a multi-player server.
  440. Deathmatch teleport generation is switched off!
  441.  
  442. The testing archive is called:   elimtst1.zip
  443.  
  444. You can grab it from http://www.iinet.com.au/~cam/quakec.html
  445. OR from ftp.cdrom.com (in the quakec/bots directory).
  446.  
  447.  
  448.  
  449. CONTACTS
  450. --------
  451.  
  452. Comments and suggestions can be emailed to me at  cam@iinet.com.au
  453.  
  454. Please DO NOT MAIL ME ASKING FOR THE SOURCE CODE.  The answer is NO.
  455. I will not reply to mail of this type.
  456.  
  457. (you can guess that this is currently the majority of mail I get - some
  458. of it is very persistant :)
  459.  
  460. All other questions will be replied to as best I can.  Please note
  461. that I will not be available after the 21st of September 1996.
  462.  
  463. Thanks,
  464. c.
  465.  
  466.